A Specification Language for Distributed Components Implemented in GCM/ProActive

1.1 Introduction This technical report is based on a component model for distributed components called GCM for Grid Component Model. We present here this component model, its reference implementation based on the Java middleware ProActive, our specification language JDC adapted to distributed components, and the associated specification platform: Vercors. Our aim is, from the specification of components and their behaviour, to be able to both verify properties of this behaviour and generate real GCM components. The OASIS team works in the area of distributed systems, with a stress on programming methodology and tools for computing grids. Analysing the behaviour of distributed systems always has been more difficult than for traditional systems, because of the complexity of temporal interactions between remote parts of the application. We base our programming model on active objects: each active object has its own (and unique) thread, processing asynchronous method calls on the object. This model is intended to ease the analysis of con-currency by clearly identifying entry points for communications and limiting the concurrency aspects to remote method calls on the same object. Moreover, structuring distributed systems using components is somewhat better, because it requires that interaction points (service points, but also required interfaces) are well defined. Additionally, having well-defined components boundaries reduces the amount of information that one component needs to have of its environment. The active object paradigm together with a distributed hierarchical component model provide convenient abstractions that help programmers understand the interactions between their different pieces of codes. Indeed in GCM/ProAc-tive communication and concurrency is provided by asynchronous method calls between well-defined interfaces, and transparent channels transmitting the results of those calls. Unfortunately, developers still have to face non-trivial runtime incompatibilities when assembling off-the-shelf components. These incompatibilities arise due to the lack of a precise dynamic specification of the component behaviour (the protocols for inter-component communication). In fact, state-of-the-art implementations of component models such as Fractal [1] and the CORBA Component Model [2] only consider interface type-compatibility for binding interfaces. Nonetheless, a much more precise, sound static compatibility check of bound interfaces can be achieved if behavioural information is added to the components. In such effort, we proposed in [3] to attach behaviour as part of the architecture specification, defined in terms of parameterized networks of transition systems. The compatibility between these behaviours could be checked using model-checkers as we did in [4]. In the same spirit, " behavior protocols " …